On 18 Nov 1998 06:04:43 -0500, Margus Ramst <mar### [at] peakeduee> wrote:
>OK, I don't know exactly if I should bug Ron directly or post it here an hope
>he sees it. Since this isn't a bug report but rather a new feature request,
>I'll post it here and see what others think about it.

Normally, I'd say you should bug me directly, but since I ended up
asking for outside opinions on this one anyway, I think it's okay.
Maybe I should get Twyst to make me a superpatch forum on 
PatchStation.  (That's not too farfetched: that's currently the
only place to get the superpatch, so why not support it there?)

>The trace function in the Superpatch is a wonderful thing, but 2 things would
>make it even more wonderful (in my opinion, at least):
>
>1) It is rather cumbersome check the normal vector to confirm an intersection -
>maybe a new Boolean flag as an indicator?

This is true.  I thought about having it take two vector parameters 
and store the intersection and normal into them, returning a boolean 
for whether it succeeded or failed.  The only problem with this is it 
makes it less friendly for cases when you know there'll be an 
intersection, as you can currently do this in that case:
  sphere { trace( my_hfield_obj, Start_Vect, -y ), .5 }

You could, of course, use "#if (vlength(mynormal))" but that's a
few more operations (including a square root) than you really need.

I agree that there's a problem.  Perhaps the proper solution is to 
make it easier to compare vector quantities, so that something like
"#if (mynormal=0)" will work.  Then, the code to compare the normal 
vector would be almost the same as the code to compare a boolean, 
without having to add yet another parameter to an already big list.

Right now, inexplicably, the expression "mynormal=0" returns a 
vector with true wherever the corresponding component of
mynormal is zero and false wherever it's not.  This is a
completely nonintuitive result, and I'd be surprised if anyone
actually uses it.  Unfortunately, this behavior is documented,
so I'm not sure what to do about it.  Should we realize we're
parsing a conditional expression with the expectation of getting
a single float value and parse relational operators differently 
in that case?  How do you parse <, <=, >, and >= as vector 
operators returning a scalar value?  Opinions on this, especially 
from people who are using the rather bizarre current semantics, 
are welcome.

>2) Something I'm currently working at requires a check whether an intersection
>occurred within a specified distance from the start point. This extra check is
>rather slow; therefore I'd like to have an option of specifying the length of
>the trace vector and have trace() return 0 (no intersection) when this length
>is exceeded.

Again, this requires an additional parameter, though it would be 
easy enough to add an optional parameter on the end after the 
already-optional normal vector.  Realize, though, that this won't
gain you as much as you might think (except a tiny bit of parse 
time) over testing the result yourself, because the built-in trace 
functions don't have any limits on depth.  That is, it'd still have 
to find all the intersections and check the distance to the closest 
one, just like you're doing now in POV code.  Of course, some 
objects could have more optimal tests, but that would make for
some pretty big changes.

Post a reply to this message